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Abstract 

A visual programming language may help a 
computer programmer develop computer 
programs [9]. Diagrams based on Petri’s net 
elements have been used to model systems from 
a wide range of disciplines for control, 
simulation, analysis and communication [5, 12, 
15, 17]. Diagrams based on Holt’s net elements, 
an extension to Petri’s net elements, may be 
used to organize parts of a computer program. 
The system of computer program organization 
or annotation system considered here includes 
Holt’s net elements, annotation classes, a system 
for creating names for identifiers, and a form 
view of an annotations database. With a Petri 
Net diagram and this annotation system, it 
should be possible for a computer programmer 
to systematically develop computer programs. 
The computer programs considered here are 
JavaScript™ programs in PDF documents; they 
interact with some of the objects of the 
Acrobat™/JavaScript API to realize token 
games and other form-based applications. 

Introduction 

Net Coding Workflow (Figure 1). Annotations 
of net elements may be used to organize logic 
computations such as parts of a computer 
program [19]. Examples of logic annotations 
include tests conditions for inputs and 
transitions; firing rules for transitions; and 
weight computations for input or output arcs [7, 
8 , 21 ]. 

The logic annotations of net elements include 
computations of net element properties or call 
on logic annotations of corresponding or related 
net elements. They may also call on or receive 
calls from view annotations. The view 
annotations of net elements interface with the 
displays and events (user and system) of a host 
environment. 



Figure 1 Net Coding Workflow 

It should be possible to maintain a database (dB) 
of the net elements and their annotations directly 
or via a form. The assembly of logic annotations 
of net elements and of view annotations from 
the database is part of an application’s computer 
program (Code). 

Net Programming Workflow (Figure 2). A 

visual programming language may help a 
computer programmer develop computer 
programs [9]. Instead of working directly with 
the database or a form, a computer programmer 
may use a graphics-based editor to create, edit 
and annotate net elements. Every graphics 
object in the editor stands for a net element or 
an annotation. The objects should map to the 
database. 



Figure 2 Net Programming Workflow 

Net Programming Workflow with 
Generators and Patterns (Figure 3). For 

descriptions with too many elements or patterns 
of logic or repeated components, it would be 
challenging to work directly with the database, 
to fill the forms, or to use a graphics editor [16, 
19]. To mitigate the challenge, a graphics object 
may represent more than one net element of the 
same type [16]; it may also represent more than 
one net element of different types [20]. An 
element generator, a special type of annotation, 
may be used to map a graphics object to more 
than one net element. An element pattern, a set 
of commonly used element generators, may be 
used to facilitate the application of several 
element generators. A logic generator, another 
special type of annotation, may be used with an 
element generator to create logic annotations. A 
logic pattern may be used to facilitate the 
application of several logic generators. 


Figure 3 Net Programming Workflow with Generators and 
Patterns 

Net Integration Workflow (Figure 4). The 

computer programs considered here are 
JavaScript™ programs in PDF documents; they 
interact with some of the objects of the 
Acrobat™/JavaScript API (such as Field, Doc 
and app) to realize token games and other form- 
based applications [1, 2, 6]. 

The computer program (Code) is integrated into 
the master PDF document (Inter. PDF). Some of 
the objects in the graphics editor (Gfx & Ann.) 
and supporting documents (Supp. Docs.) are 
converted to PDF documents, and imported into 
the master PDF document. Utility programs 
(Utils.) integrate codes. Code integration 
includes the importation of computer codes (e.g. 
the importation of JavaScript programs as 
document-level scripts) and supporting PDF 
documents; and the one-time creation of objects 
(e.g. the addition of field objects). 



Figure 4 Net Integration Workflow 

Net Programming and Integration 
Workflows (Figure 5). The system of computer 
program organization considered here supports 
the workflows for net programming using 
JavaScript, and integration with PDF using the 
Acrobat/JavaScript API. It may be used as a 
basis for visual programming languages 
designed to realize token games and other form- 
based applications in PDF. 



Figure 5 Net Programming and Integration Workflows 


Net Viewing and Interactions (Figure 6). For 

token games and other form-based applications 
in PDF, the viewing experience of a user is an 
interactive process. The interaction includes 
activities that a user may not or cannot perceive. 
Examples of activities are initialization ( i ) 
activities triggered by the opening of a PDF 
document, process (p) activities triggered by 
user or system events, computation (c) activities 
for updating properties of net elements, and 
update ( u ) activities for notifying the host 
environment of related changes [1,6]. 



update 


compute 


Figure 6 Net Viewing and Interactions 


Net Theory 

Petri’s Net Theory. The elements of Petri’s net 
are place, transition, input and output - an input 
connects a place to a transition and an output 
connects a transition to a place [10, 20]. Every 
net element may have an inscription, a tag or an 
annotation [19]. Net elements and net element 
inscriptions may be used to describe a wide 
range of systems at various levels of 
abstractions and for many purposes - such as 
control, simulation, analysis and communication 
[19]. For example, they may be used to describe 
system components in prose, to present system 
parts using graphics, and to specify system 
modules in terms of mathematical expressions 
or computer codes [19]. 


Net Elements 

Holt’s net elements. The net elements 
considered here are place (P), transition (7), 
input (In), output (Ou), runners (R) and net (N). 
In other words, Holt’s net elements are Petri’s 
net elements plus the runner and the net. The 
runner is an object that is responsible for a set of 
transitions; it may be associated with a 
computer processor. Every net element has a 
unique identifier (ID). Every place (P) as a 
place identifier (pID). Every transition (T) has a 
transition identifier (tID). Every input (In) has 
an input identifier (elD). An input connects a 
place to a transition - thus it has a related input 
place (pID) and transition (tID). Every output 
(Ou) has an output identifier (elD). An output 
connects a transition to a place - thus it has a 
related output place (pi D) and transition (tID). 
Every runner (R) has a runner identifier (elD). 
And the net (N) has a net identifier (n) 



Figure 7 Net Elements 


Annotation System 

This annotation system can be used as a guide to 
create a wide variety of token games and other 
form-based applications. It is based on the 
author’s experiences (from 201 1 - 2014) in 
creating token games for Inhibitor Nets or nets 
with flexible arcs using JavaScript in PDF; in 
using several objects (such as the Field, Doc and 
app objects) of the Acrobat/JavaScript API; and 
in using Word, PowerPoint and Acrobat Pro [1, 
2, 4, 6, 13, 14]. With this annotation system a 
computer programmer or software developer or 
software engineer should be able to 
methodically specify custom annotations for 


updating properties of net elements, and 
visualizing and interacting with net elements 
and net element properties. It is a system for 
organizing net element annotations. 

Classes of Annotations 

There are six classes of annotations. First, 
property annotations of net elements. Second, 
logic annotations of net elements. Third, view 
annotations of net elements. Fourth, logic 
annotations of view annotations of net elements. 
Fifth, view annotations of property annotations 
of net elements. And sixth, logic annotations of 
view annotations of net elements and of 
property annotations of net elements. Every 



element may have any number of annotations. 
However it is unnecessary for an element to 
have every available annotation. Thus 
annotations should be selected for each net 
element to satisfy a particular token game or 
form-based application. The following selection 
is a set of annotations suitable for creating token 
games. 

Property Annotations of Net Elements. A 

place has a mark ( m ). A transition has a status 
(s t ). Every input has a weight (w~) and a status 
(s“). Every output has a weight (w + ) and may 
have a status (s + ). The values of 
properties m,w ~ , and w + may come from any 
domain such as the sets of Natural Numbers, 
Real Numbers, and n- bit Floating Point 
Numbers; or they may come from structured 
information such as the ones used in 
Predicate/Transition Nets [7], Coloured Petri 
Nets [8] and Algebraic Nets [21]. A status can 


be enabled or not enabled. If the status of a net 
element is enabled, the net element can fire. If 
the status of a net element is not enabled, the net 
element cannot fire. A runner may have a status 
(s r ) and it is responsible for one or more 
transitions (£ r ). Also it has one or more run 
logic (rn), one or more start logics (st), one or 
more stop logics (sp), one or more running 
frequencies (ms), and one or more interval or 
timeout objects ( ai ). A run logic is a sequence 
of steps for firing one or more transitions and 
performing necessary updates. A start logic is a 
sequence of steps for starting an interval or 
timeout object. A stop logic is a sequence of 
steps for stopping an interval or timeout object. 
A running frequency is an amount of time in 
milliseconds between the call of a run logic and 
the next call of the same run logic. The Net may 
have a net (n) property. It also has a document 
(dc) and the app (ap) properties [2]. 



Figure 8 Property Annotations 


Logic Annotations of Net Elements. The Is 

Enabled ( iE ) logic annotation updates the status 
of a net element or calls on the Is Enabled logic 
annotation of related net elements. References to 
the Is Enabled annotation for transition, input 
and output are iE 1 , iE~ and iE+ respectively. 

The Fire ( F ) logic annotation updates the mark 
of a related place or calls on the Fire logic 
annotation of related inputs and outputs. 
References to the Fire logic annotation for 
transition, input and output are F t , F~ and F + 
respectively. The Get Weight (gW) logic 
annotation updates the weight of an input or an 


output [21]. It may also call on the Get Weight 
logic annotation of related inputs and outputs. 
References to the Get Weight logic annotation 
for transition, input and output 
are gW t ,gW~ and gW + respectively. The Start 
(s£) logic annotation begins the interval or 
timeout object of a run in a runner [2]. The Stop 
(sp) logic annotation ends the interval or 
timeout object of a run in a runner [2]. The Run 
(rn) logic annotation sends a fire message to 
one or more enabled transitions of the runner 
and sends related update messages. 




Logic Annotations 


Figure 9 Logic Annotations 


View Annotations of Net Elements. The view 
annotations of net elements interface with the 
display or events of a host system. Each of the 
net elements may have an Event ( Ev ), Label (L) 
or Graphics ( Gx ) annotation. The Event 


annotation is used to capture and process user 
events. The Label annotation is a visual text that 
should uniquely identify a net element. The 
Graphics annotation is a visual representation of 
a net element. 



Figure 10 View Annotations 


Logic Annotation of View Annotations of Net 
Elements. 

The Event (Ev) annotation is the logic 
annotation of view annotations of net elements. 
The logic annotation is the computation that 
must be performed when the related user event 
or system event occurs. The event annotation of 


a transition or a net responds to one or more 
user events. The event annotation of a runner 
responds to one or more system events. A user 
event is an occurrence based on end user actions 
- such as a mouse event. A system event is an 
occurrence based on a computer system action - 
such as a timing event. The event annotation is 
based on the Field object (type: button) [1, 2, 3]. 






Figure 11 Logic Annotations of View Annotations 


View Annotations of Property Annotations. 

Property annotations may have zero or more 
view annotations: Text ( Tx ), Icon (/c) and 
Display ( D ). The view annotation of a property 
should interface with an external system or host 
environment. A text annotation is a textual 


visualization of a property annotation. A display 
annotation is a graphic visualization of a 
property annotation. An icon annotation is a 
source of images to the corresponding display 
annotation. These annotations are based on the 
Field object (type: text, button) [1, 2, 3]. 



Figure 12 View Annotations of Property Annotations 


Interactions of View Annotations. Every view 
annotation ( Ev , Tx , /c, D ) is an interface to the 
host environment. It is based on the Field object 
(type: text, button) [1, 2, 3]. It may be added to 
a PDF document (a), initialized when its PDF 
document is opened (i), and may update its host 
when needed ( u ). System and user events may 
also be processed ( pEv ). 



Table 1 Annotation versus Interaction 

For the token games considered here, every place mark has a display view ( D m ). Each display view must 
have an initialize ( iD m ) and update ( uD m ) logic; it has a source icon ( Ic m ) that must have an initialize 
( ilc m ) logic. Every transition status has a display view ( D st ). Each display view must have an initialize 
(iD st ) and update ( uD st ) logic; it has a source icon ( Ic st ) that must have an initialize ( ilc st ) logic. The 
event annotation of a transition must have initialize ( iEv st ), process ( pEv st ) and update ( uEv st ) logic; it 






has a source icon ( Ic st ) that must have an initialize ( ilc st ) logic. The event annotation of a runner ( Ev R ) 
must have an initialize ( iEv R ), process (pE v R ) and update ( uEv R ) logic. The display annotation of a net 
(D n ) must have an initialize ( Di n ) logic. The event annotation of the net ( Ev n ) may have an initialize 
(iEv n ) and process ( pEv n ) logic. 



Logic Annotations of View 
Annotations of Property 
Annotations 


Figure 13 Logic Annotations of View Annotations of Property Annotations 

A Guide to Computer Programming 

The Net Programming and Integration Workflows (Figure 5) may be broken down into five steps: 

1 . Draw Petri Net diagram. 

2. Create supporting graphics (e.g. tokens for place marks, colours for transition status). 

3. Using the Petri Net diagram and the template Form Views as guides: 

a. Create Logic and View Annotations Form 

i. Create net element and annotation headings. 

ii. Generate net element identifiers. 

iii. Create annotation identifiers. 

b. Create Annotation-Interaction Form 

i. Create net element and annotation headings. 

ii. Generate net element identifiers. 

iii. Create annotation identifiers. 

4. Using the Petri Net diagram and the filled-in forms as guides: 

a. Create JavaScript program. 

5. Integrate PDF documents and JavaScript program. 

A vector-based graphics editor may be used to draw a Petri Net diagram. Software capable of editing 
tables may be used to create annotation forms. And a text editor may be used to create JavaScript 
programs. To facilitate the creation of annotation forms, the addition of form entries, and the creation of 
JavaScript programs: a template for logic and view annotations form, a template for annotation- 
interaction form template, and a naming convention for identifiers may be used as guides. 

Logic and View Annotations Form Template. The following is a template for logic and view 
annotations for net elements, a special form view with generic identifiers. A generic identifier is a 
prototype naming convention that can be completed by adding element identifiers (such as values from 
ID, elD, pID, or tID ) as subscripts to the prototype. The identifier may be mapped to a JavaScript 
identifier as follows: [ interaction \ < annotation >< property /type >< identifier >. 
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Figure 14 A Template for Net Element Annotations and a Naming Convention 

Annotation-Interaction Form Template. Additional logic annotations are needed to handle interactions 
for view annotations. Figure 15 is a summary of logic annotations for interactions that may be used to 
create token games and other form-based applications. 



Figure 15 Net Elements View Annotation-Interaction Form 
The following rules may also help implement the JavaScript program: 

1 . A Petri Net model may be implemented as a constructor. 

2. There are two ways to implement the property annotations. Each property group (e.g. m, s t , w~, 
s~ , w + , etc.) may be an array or each property (e.g. m 0 , ra 1? Sq, ■■■? s o, s i > ■■■? w o ? w i> 

...) is a direct reference to the actual property. 

3. Properties (including all the properties of Runner ( R ) and Net (A)) that are not modified by the 
logic annotations (e.g. np, nt, ni, no, etc.) should be implemented as prototypes. Each group of 
logic annotation (e.g. iE T , iE~, F T , etc.) may be an array of functions or each logic annotation 
(e.g. IEq , iE\, iE\, etc.) is a direct reference to a function. 

4. Logic annotations should be implemented as function prototypes of the constructor. 

Example: A Single Server Queuing System 

Consider a single server queuing system based on the description of the Simulation of a Single-Server 
Queuing System [11]: Customers arrive at a service station and form a queue. There are three servers at 
the service station. When a server is available, the customer in front of the queue may begin service. It 
takes a random amount of time for the server to process the service. After the service, the customer 
leaves the service station and the server is available for the next customer. When the fifth customer 
begins service, the system stops. Figure 17 is a Place-Transition Net diagram of this queuing system. The 
related forms and source code follow. 






Figure 16 A Place-Transition Net Diagram of a Single Server Queuing System 
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Single Server Queuing System-. 
Event Annotation — Interaction 


Annotation — Interaction 
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Single Server Queuing System : 

Text, Icon, Display AnnotaXion — Interaction 


Net Elements 
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Single Server Queuing System-. 
Sample JavaScript Source Code 

function SSQl(parms) { 

prototype.uD_s_t_l = fimction() { 


var i; 

if (this.s_t[l]) 

prototype. pEv T 1 = function() { 

this, id = parms.id; 

this.D s t[l].buttonSetIcon( 

this.F_T_l(); 

this.m = []; 

this.Ic_s_t[l][l] ); 

this.iE T 0(); 

for (i=0; i<this.np; i++) 

else 

this.iE T 1(); 

this.m[i] = 0; 

this.D_s_t[ 1 ] .buttonSetIcon( 

this.iE_T_2(); 

this.st = []; 

this.Ic s t[l][0] ); 

this.uD_m_0(); 

for (i=0; i<this.nt; i++) 

} 

this.uD_m_l(); 







this.s_t[i] = undefined; 

prototype. uD_s_t_2 = fimction() { 

this.uD_m_2(); 

this.w_in = []; 

if (this.s_t[2]) 

this.uD_m_3(); 

this.s_in = []; 

this.D s t[2].buttonSetIcon( 

this.uD_s_t_0(); 

for (i=0; i<this.ni; i++) { 

this.Ic_s_t[2][l] ); 

this.uD s t 1(); 

this.w_in[i] = 1; 

else 

this.uD s t 2(); 

this.s in[i] = undefined; 

this.D_s_t[2] .buttonSetIcon( 

this.uEv_T_0(); 

} 

this.Ic s t[2][0] ); 

this.uEv_T_l(); 

this.w_ou = []; 

} 

this.uEv T 2(); 

for (i=0; i<this.no; i++) 

prototype. uEv T 0 = function() { 

} 

this.w_ou[i] = 1; 

if (this.s_t[0]) 

prototype. pEv T 2 = fimction() { 

this.sr = undefined; 

this.Ev_T[0]. display = 

this.F T 2(); 

this.tr = []; 

display, visible; 

this.iE_T_l(); 

this.etr = undefined; 

else 

this.iE T 20; 

this.ms = 1000; 

this.Ev_T[0]. display = 

this.uD_m_2(); 

this.ai = undefined; 

display.hidden; 

this.uD_m_3(); 

this.D n=[]; 

} 

this.uD s t 1(); 

this. Dm = []; 

prototype. uEv T 1 = fimction() { 

this.uD_s_t_2(); 

this.Ic_m = []; 

if (this.s_t[l]) 

this.uEv_T_l(); 

this.Ev_T = []; 

this.Ev_T[l]. display = 

this.uEv T 2(); 

this.D_s_t = []; 

display, visible; 

} 

this.Ic_s_t = []; 

else 

prototype. pEv_N_0 = function() { 

this.Ev R=[]; 

this.Ev_T[l]. display = 

this.iD_n(); 

} 

display.hidden; 

this.iD_m(); 

with (SSQ1) { 

} 

this.ilc_m(); 

prototypes = 0; 

prototype. uEv_T_2 = fimction() { 

this.iD_s_t(); 

prototype, ap = app; 

if (this.s_t[2]) 

this.ilc_s_t(); 

prototype.de = this; 

this.Ev_T[2]. display = 

this.iEv_T(); 

prototype. np = 4; 

display, visible; 

this.iEv_R(); 

prototype. nt = 3; 

else 

var i; 

prototype. ni = 6; 

this.Ev_T[2]. display = 

this.m[0] = 5; 

prototype.no = 5; 

display.hidden; 

this.m[l] = 0; 

prototype.iD_n = function() { 

} 

this.m[2] = 0; 

this.D_n[0] = 

prototype.iE_In_0 = function() { 

this.m[3] = 2; 

this.dc.getField(”SSQl$" + this. id 

if (this.m[0] < 1) 

for (i=0; i<this.np; i++) 

+ "$D n$ M + 0); 

this.s_in[0] = false; 

eval("this.uD_m_" + i + "();"); 

} 

else 

for (i=0; i<this.nt; i++) { 

prototype.iD_m = function() { 

this.s in[0] = true; 

eval(”this.iE T " + i + "();"); 

var i; 

} 

eval(”this.uD s t ?? + i + ”();”); 

for (i=0; i<this.np; i++) 

prototype.iE In 1 = function() { 

eval(”this.uEv T " + i + "();"); 

this.D_m[i] = 

if (this.m[0] < 1) 

} 

this.dc.getField("SSQl$" + this. id 

this.s_in[l] = false; 

if (this.ai) 

+ "$D m$ M + i); 

else 

this.sp(); 

} 

this.s in[l] = true; 

this.Ev_R[0].fillColor = 

prototype, ilcm = fimction() { 

} 

color.green; 

var i,j; 

prototype.iE In 2 = function() { 

} 

for (i=0; i<this.np; i++) { 

if (this.m[l] < 1) 

prototype.rn = function(){ 

this.Ic_m[i] = []; 

this.s_in[2] = false; 

var i; 

for (j=0;j<7;j++) 

else 

this.etr = []; 

this.Ic_m[i][j] = 

this.s in[2] = true; 

for (i=0; i<this.nt; i++) { 

this.dc.getField( M Token$ M + 

} 

if (this.s_t[i]) 

j ) .buttonGetIcon() ; 

prototype.iE_In_3 = function() { 

this.etr [this.etr. length] = i; 

} 

if (this.m[3] < 1) 

} 

} 

this.s_in[3] = false; 

if (this.etr.length>0) { 

prototype.iD_s_t = function() { 

else 

i = Math.round((this.etr.length- 

var i; 

this.s in[3] = true; 

1 ) *Math.random()) ; 

for (i=0; i<this.nt; i++) 

} 

switch(this.etr[i]) { 

this.D_s_t[i] = 

prototype.iE In 4 = fimction() { 

case 0: 

this.dc.getField("SSQl$" + this. id 

if (this.m[0] < 1) 

this.pEv_T_0(); 

+ M $D s t$" + i); 

this.s_in[4] = false; 

break; 

} 

else 

case 1: 

prototype. ilc s t = function() { 

this.s in[4] = true; 

this.pEv_T_l(); 

var i; 

} 

break; 

for (i=0; i<this.nt; i++) { 

prototype. iE_In_5 = function() { 

case 2: 




this.Ic_s_t[i] = []; 

if (this.m[2] < 1) 

this.pEv_T_2(); 

this.lc_s_t[i][0] = 

this.s_in[5] = false; 

break; 

this.dc.getField(”Colour$NotEnable 

else 

default: 

d" ) .buttonGetIcon() ; 

this.s in[5] = true; 

break; 

this.Ic_s_t[i][l] = 

} 

} 

this.dc.getField(”Colour$ 1 f, ).button 

prototype.iE_T_0 = fimction() { 

} else 

GetIcon(); 

this.iE_In_0(); 

this.sp(); 

} 

this.s t[0] = this.s in[0]; 

} 

} 

} 

prototype. uEv_R_0 = function() { 

prototype. iEv_T = function() { 

prototype.iE_T_l = fimction() { 

if (this.ai) 

var i; 

this.iE In 1(); 

this.Ev R[0].fillColor = 

for (i=0; i<this.nt; i++) 

this.iE In 2(); 

color.red; 

this.Ev T[i] = 

this.iE In 3(); 

else 

this.dc.getField( M SSQl$" + this. id 

this.s _t[l] = this.s_in[l] && 

this.Ev R[0].fillColor = 

+ "$Ev T$" + i); 

} 

prototype. iEv_R = function() { 

this.s_in[2] && this.s_in[3]; 

color.green; 

i 

prototype. iE_T_2 = function() { 

i 

prototype. st = function() { 

this.Ev_R[0] = 

this.iE In 4(); 

this.sr = true; 

this.dc.getField(”SSQl$" + this. id 

this.iE_In_5(); 

this.ai = 

+ "$Ev R$0"); 

this.s _t[2] = this.s_in[4] && 

this.ap.setlnterval("agent[" + 

} 

this.s in[5]; 

this. id + "].rn(); M , this.ms); 

prototype. uD_m_0 = function() { 

} 

this.uEv R 0(); 

if (this.m[0] < 

prototype. F_ln_0 = fimction() { 

} 

this.lc_m[0]. length) 

this.m[0] -= 1; 

prototype. sp = function() { 

this.D_m[0] .buttonSetIcon( 

} 

this . ap . clearlnterval(this . ai) ; 

this.Ic m[0][this.m[0]] 

prototype. F_In_l = fimction() { 

this.ai = undefined; 

); 

this.m[0] -= 1; 

this.sr = undefined; 

else 

} 

this.etr = undefined; 

this.D_m[0] .buttonSetIcon( 

prototype.F_In_2 = fimction() { 

this.uEv R 0(); 


this.m[l] -= 1; 

} 

this.Ic m[0] [this.Ic m[0]. length- 1] 

} 

prototype .pEv_R_0 = function() { 

); 

prototype.F_In_3 = fimction() { 

if (this.ai) 

} 

this.m[3] -= 1; 

this.sp(); 

prototype. uD_m_l = function() { 

} 

else 

if (this.m[l] < 

prototype.F_In_4 = fimction() { 

this.st(); 

this.Ic_m[ 1 ] .length) 

this.m[0] -= 1; 

} 

this.D_m[ 1 ] .buttonSetIcon( 

} 

} 

this.Ic m[l][this.m[l]] 

prototype.F_In_5 = fimction() { 

var agent= []; 

); 

this.m[2] -= 1; 

(function() { 

else 

} 

var id = 1401414769; 

this.D_m[ 1 ] .buttonSetIcon( 

prototype. F_Ou_0 = function() { 

agent[id] = new SSQl({id: id}); 


this.m[0] += 1; 

with (agent [id]) { 

this.Ic m[l] [this.Ic m[ 1]. length- 1] 

} 

pEv N 0(); 

); 

prototype. F_Ou_l = function() { 

} 

} 

this.m[l] += 1; 

})(); 

prototype. uD_m_2 = function() { 

} 


if (this.m[2] < 

prototype.F_Ou_2 = function() { 


this.Ic_m[2]. length) 

this.m[2] += 1; 


this.D_m[2] .buttonSetIcon( 

} 


this.Ic m[2][this.m[2]] 

prototype.F_Ou_3 = function() { 


); 

this.m[0] += 1; 


else 

} 


this.D_m[2] .buttonSetIcon( 

prototype. F_Ou_4 = function() { 
this.m[3] += 1; 


this.Ic m[2] [this.Ic m[2]. length- 1] 

} 


); 

prototype. F_T_0 = fimction() { 


} 

this.F Ou 1(); 


prototype. uD_m_3 = function() { 

} 


if (this.m[3] < 

prototype.F_T_l = fimction() { 


this.Ic_m[3]. length) 

this.F_In_l(); 


this.D_m[3].buttonSetIcon( 

this.F_In_2(); 


this.Ic m[3][this.m[3]] 

this.F_In_3(); 


); 

this.F_Ou_2(); 





else } 

this.D_m[3].buttonSetIcon( 

this . Ic_m[3 ] [this . Ic_m[3 ] . length- 1 ] 

); 

} 

prototype. uD_s_t_0 = function/) { 
if (this.s_t[0]) 

this.D_s_t[0] .buttonSetIcon( 
this.lc_s_t[0][l] ); 
else 

this.D_s_t[0] .buttonSetIcon( 
this.lc_s_t[0][0] ); 

_j 


prototype. F_T_2 = function/) { 
this.F_In_5(); 
this.F_Ou_4(); 

} 

prototype .pEv_T_0 = function/) { 
this.F_T_0(); 
this.iE_T_l(); 
this.uD_m_l(); 
this.uD_s_t_l(); 
this.uEv_T_l(); 

} 


Conclusion 

With a Petri Net diagram and the annotation system, it is possible to systematically create JavaScript 
programs. A Petri Net diagram is a useful guide for systematically establishing the input-output relations 
of places and transitions. The annotation system is a useful companion to a Petri Net diagram for 
systematically building the properties and logic computations of an application. The annotations may be 
added to the net elements or net element properties. The addition may be performed in a database, a form 
or objects of a graphics editor. To facilitate the annotation process, several classes of annotations, a form 
view of the annotations, and a form view of the annotation-interactions are included in the annotation 
system. The computer programs are JavaScript programs that run in PDF documents. They interact with 
AcroForm objects (app, Document and Field objects) using the Acrobat/JavaScript API 
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